The "ns16550: Add support for UART present in Broadcom TruManage
capable NetXtreme chips" implies that only devices that are have
an MMIO BAR and are in the quirks table should be processed.
Even the comment at the end says so:
If we have an io_base, then we succeeded in the lookup
But the code was checking for the !io_base - which is to say if
the io_base was 0 then we would skip scanning. But io_base
always has a value - it is set by 'ns16550_init' to a default
value - so it would never hit the 'continue' path.
This means that if we have an communication device followed by
a serial AMT device we would pick the communication device instead
of the AMT device.
See:
00:16.0 Communication controller: Intel Corporation Cougar Point HECI Controller #1 (rev 04)
Subsystem: Intel Corporation Device 2008
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at
fb12a000 (64-bit, non-prefetchable) [size=16]
00:16.3 Serial controller: Intel Corporation Cougar Point KT Controller (rev 04) (prog-if 02 [16550])
Subsystem: Intel Corporation Device 2008
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 17
I/O ports at f0e0 [size=8]
Memory at
fb129000 (32-bit, non-prefetchable) [size=4K]
pci 0000:00:16.0: [8086:1c3a] type 00 class 0x078000
pci 0000:00:16.3: [8086:1c3d] type 00 class 0x070002
And Xen picks 00:16.0 as its console when using 'com1=115200,8n1,amt'.
This patch fixes it and allows us to use AMT again by zeroing
out io_base to zero. If the scan did not work, the io_base is
set back to a default value (the 'pci_uart_config' does that
already at its end).
Tested-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
CC: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
CC: Thomas Lendacky <Thomas.Lendacky@amd.com>
CC: Keir Fraser <keir@xen.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>